1. Field of the Invention
This invention relates to inventory management of highly configurable systems which may be relocated from one physical environment to another.
2. Background of the Invention
As business demand increases, the depth of technology improvements and its intelligence to handle multiple processes becomes highly desirable and crucial. In any enterprise operation, it is difficult to effectively manage the ever-fluctuating resources available, while maximizing the resource utilization.
In fact, Information Technology (“IT”) costs can become very expensive when maintaining sufficient resources to meet peak requirements. Furthermore, user inputs are generally required to facilitate such processes, which incurs additional costs in both time and human resource demand.
To address these needs, many large vendors of enterprise computing systems, such as International Business Machines (“IBM”), Hewlett-Packard (“HP”), Microsoft Corporation, and Sun Microsystems (“Sun”), have begun to develop and deploy infrastructure technologies which are self-managing and self-healing. HP's self-managed computing architecture is referred to “Utility Computing” or “Utility Data Center”, while Sun has dubbed their initiative “N1”. IBM has applied terms such as “Autonomic Computing”, “Grid Computing”, and “On-Demand Computing” to their various architecture and research projects in this area. While each vendor has announced differences in their approaches and architectures, each shares the goal of providing large-scale computing systems which self-manage and self-heal to one degree or another.
For example, IBM's Autonomic Computing is a self-managing computing model which is patterned on the human body's autonomic nervous system, controlling a computing environment's application programs and platforms without user input, similar to the way a human's autonomic nervous system regulates certain body functions without conscious decisions.
Additionally, IBM has defined their On-Demand Computing technology as an enterprise whose business processes, integrated end-to-end across the company and with key partners, suppliers, and customers, can respond quickly to any customer demand, market opportunity, or external threat.
“Provisioning” is a term used to describe various aspects of managing computing environments, and which often implies different things to different parties. Throughout the present disclosure, we will use the term “provision” or “provisioning” to refer to a sequence of activities that need to happen in a specific order in order to realize a computing environment to meet specific needs and requirements. The activities have dependencies on previous activities, and typically include:                (a) selecting appropriately capable hardware for the requirements, including processor speed, memory, disk storage, etc.;        (b) installing operating system(s);        (c) remotely booting networks;        (d) configuring networks such as Virtual Private Networks (VPN) and storage environments like Storage Area Network (SAN) or Network Attached Storage (NAS); and        (e) deprovisioning resources that are no longer needed back into an available pool.        
Operating environments in large data centers have become increasingly complex. These data centers usually require a long time to modify their environments, so most provision for the worst-case scenario, often configuring more hardware than is needed just in case a peak requirement is experienced. As a result, most hardware and software resources are under-used, increasing the costs of the system considerably. Furthermore, the issue of surges beyond what has been provisioned remains unaddressed (e.g. peak demands above the anticipated peak load).
In fact, provisioning is typically a time and labor consuming process consisting of hundreds of distinct and complex steps, and requiring highly skilled system and network administrators. For example, server provisioning is the process of taking a server from “bare metal” to the state of running live business transactions. During this provisioning process, many problems may arise such as increases in resource expense and declines in level of performance, which in turn can lead to dissatisfied customers and unavailability in services.
Because these are predictable issues, automation can be employed to manage these problems. One objective of the various of self-managed computing systems being offered by the major vendor is to automate to an extent as great as possible these provisioning activities, and especially to allow for near real-time reactions to changes in system requirements and demands, with little or no human administrator intervention. For example, IBM's Tivoli™ Provisioning Manager (“TPM”) Rapid Provisioning is a modular and flexible set of workflows and scripts for the IBM Tivoli Intelligent Orchestrator product. The workflows have been generalized and packaged for customization by customers seeking to accelerate their provisioning process. They can be used as a starting point for an organization in automating not only their server provisioning process, but also other IT processes.
Other products currently offered by the major vendors include HP's OpenView OS Manager using Radia which is a policy-based provisioning and ongoing automated management tool for a variety of operating systems, and Sun's N1 Grid Service Provisioning System automates to some degree the provisioning of applications.
Turning to FIG. 3, the typical IT environments for an organization are depicted. When a new application program or server configuration is created, most development is conducted in a Development Environment (31). This can include “standard” software packages, such as database programs, as well as custom software components, such as Java Beans, and their configurations to perform a specified set of business operations. Often, the hardware configurations employed during development are representative, but not identical, to the final hardware configuration which will be deployed during production. For example, the final production environment may call for 50 highly similar servers sharing a computing demand for an enterprise, but because they will each be configured with identical software, a smaller, representative environment of 10 servers may be used during development.
Once the code under development is complete, a copy or image of it is moved into a Test Environment (32), where it is preferably loaded onto a hardware environment which is an exact copy of the future production hardware environment. In this phase, any issues which did not arise during the development phase running on the representative environment should be exposed, reducing the chances of an unexpected problem (and possible loss of revenue) when the production systems are provisioned with the new code.
During testing in this environment, various scripts are initiated to verify usability and ensure requirements are met. These scripts are designed to simulate certain scenarios and conditions which are expected to occur in production, such as peak demand conditions, race conditions, contention conditions, and the like. If there are any problems found, patches and upgrades (35) are produced in the Development Environment (31) and moved into the Test Environment (32), and tests are performed until they are passed.
Once the code passes testing phase, it is released into the Production Environment (33) in a controlled fashion, where it can be used by its intended users. As the Test Environment (32) is intended to be an identical duplicate environment to the Production Environment, few problems should be experience except for problems which are unpredictable, or under conditions which were not anticipated. When problems in production do occur, corrective patches and upgrades (35) are again produced in the Production Environment (31), migrated to testing (32), and finally released into production (33).
Some enterprise management systems provide “synchronization verification” (34) which periodically ensures that no differences exists between resources in the Production Environment (33) and the Test Environment (34). Differences can “creep” into the Production Environment as some administrators may make changes directly to the hardware and/or software in the Production Environment without making corresponding changes in the Test Environment. This synchronization verification, however, can be intrusive to the operation of the system, as will be described in the following paragraphs.
Additionally, IBM's systems can produce backup images (36) of programs and data from the Production Environment, typically performed during low periods of demand as the backup operations can reduce functionality and performance during their processes. By capturing backups from the Production Environment, the chances of being able to accurately reproduce the enterprise functions in the case of a system recovery are increased.
After a Production Environment has been deployed for some time and has undergone a number of patches and upgrades, it becomes desirable to determine the inventory of the Production Systems, e.g. the processors and their speeds, the amounts of memory and disk space installed on each server, the types and revision levels of operating systems and application programs, etc. It is important to know clearly and accurately the inventory of each Production Environment as this information is needed to manage license costs, and to properly determine future upgrade and change paths.
There are a number of inventory scanning tools available, but they are often operating system, middleware or hardware specific. For example, a production environment may include 20 AIX-based servers, and 10 Windows NT-based servers. A first inventory tool may be available for determining the configuration of the AIX-based machines, but a second tool may be required to determine the configuration of the NT-based machines. As such, inventory scans are at least partially managed manually, and partially performed with a collection of specific tools and programs suited for the purpose. This produces unreliable accountability and offers a skewed representation of the production environment.
Inventory scanning in this manner is resource intensive and can overload a production environment. As a result, inventory scans often are not performed by companies in their production environment in many situations, because the resources that are required during inventory scans can adversely affect business-critical operations, such as consuming needed memory, network bandwidth, or requiring disabling crucial security measures.
An alternative to this method is to pre-scan a machine in a test environment in order to know what resources will be available in the production environment. Then, either copy the applications via Internet or physically move the machine into production environment once scanning is completed. All these methods are both time and labor intensive while offering inaccurate inventory representation.
Therefore, there exists a need in the art for a system and method which can more accurately determine the true inventory of a production environment without increased manual labor, and without impact to the performance of the production environment.